Allow quoted args in Windows cmd wrapper

The new Windows command wrapper rejects any argument containing " (validate_cmd_token), which causes valid invocations to fail before process spawn whenever a .cmd/.bat target is used with arguments that legitimately include quotes (for example JSON payloads or pre-quoted values passed via Codex args/settings). This is a regression in Windows support because those arguments are valid for downstream tools, but the wrapper now hard-errors with Windows cmd wrapper does not support double quotes in arguments. instead of launching the command.

Useful? React with 👍 / 👎.

The canExecute function returns true for all files on Windows (line 10), regardless of whether they're actually executable. This is because Windows doesn't use Unix-style execute permissions. However, this means the function will return true for any file (including .txt, .dll, etc.) on Windows.

While this is probably acceptable for the PATH-based command detection (since PATHEXT filtering happens in hasCommand), the function name canExecute is misleading. Consider renaming it to something like isFileAndExecutable or isFileForPlatform, or split it into platform-specific implementations to make the behavior clearer.

Additionally, on Windows at line 33-34, the function checks if a file with an extension exists even when iterating through PATHEXT extensions, which means it might check "cmake.exe.EXE" if someone provides "cmake.exe" as input. This is likely harmless but worth noting.

On line 840, the condition || ext.is_none() means that if a Windows executable has no extension, it will be wrapped with cmd /C. This seems incorrect - executables without extensions (though rare on Windows) should be executed directly, not through cmd.

The current logic will treat codex (with no .exe extension) as a cmd script even if it's a valid executable. While resolve_windows_executable on line 831 should find codex.exe if it exists in PATH, if the user explicitly provides a path to an extensionless executable, this will fail.

Consider changing line 840 to only wrap .cmd and .bat files, not executables without extensions. If an extensionless file needs to be executed through cmd, that should be the user's responsibility to configure.

There are two different implementations of isMacPlatform() in the codebase:

1. In src/utils/shortcuts.ts (lines 176-181): Uses /Mac|iPhone|iPad|iPod/.test(navigator.platform)
2. In src/utils/platformPaths.ts (lines 23-25): Uses platformKind() === "mac" which checks if platform string includes "mac"

These implementations differ in their detection logic and could produce inconsistent results. The shortcuts.ts implementation checks for specific Apple devices, while platformPaths.ts uses a more general substring match.

Recommendation: Consolidate to a single implementation. Since shortcuts.ts already exports isMacPlatform(), consider importing it from platformPaths.ts instead of re-implementing it. Alternatively, move the implementation to platformPaths.ts and have shortcuts.ts import from there, as platformPaths.ts seems like the more appropriate location for platform detection utilities.

The Home component icon has been changed from the Command symbol (⌘) to a FolderOpen icon. While this makes the button more platform-agnostic (the Command symbol is macOS-specific), this change seems unrelated to Windows support and appears to be a UX improvement that could have been a separate change.

The icon change makes sense from a platform-agnostic perspective, but note that this changes the visual appearance on all platforms, not just Windows. Ensure this aligns with the intended design.

The new CSS rule for .settings-select option sets background and text colors to improve readability in dropdown menus on Windows. However, this rule uses CSS variables that may not be well-defined or may have platform-specific rendering issues:

1. var(--surface-popover) and var(--text-strong) need to be verified across all themes (system, light, dark, dim)
2. Some browsers/platforms may ignore these styles for <option> elements (native styling varies significantly)
3. Consider adding a comment explaining why this is needed (likely for Windows dark mode rendering)

Test this thoroughly on Windows with all theme combinations to ensure the dropdown remains usable.

The constants DEFAULT_OPEN_APP_TARGETS and DEFAULT_OPEN_APP_ID are evaluated at module load time. This means the platform detection happens once when the module is first imported, not dynamically at runtime.

If the application is built on one platform and distributed as a universal build (though unlikely for Tauri), or if there are SSR/testing scenarios, this could lead to incorrect defaults. Consider either:

1. Wrapping these in getter functions that evaluate the platform on each call
2. Documenting that these are build-time constants
3. Ensuring the build process creates platform-specific bundles

Since this is a Tauri app with platform-specific builds, this is likely acceptable, but it should be consistent with the approach used elsewhere in the codebase.

The validate_cmd_token function rejects arguments containing double quotes, which is a security measure to prevent command injection. However, this means legitimate file paths or arguments containing quotes cannot be passed through this wrapper.

While this is a reasonable security trade-off for the current use case (opening editors/apps with workspace paths), consider documenting this limitation. Users trying to configure custom commands with quoted arguments will receive a somewhat cryptic error message about "not supporting double quotes."

Consider either:

1. Adding a more user-friendly error message that explains why quotes are rejected
2. Implementing proper escaping for quotes within the cmd.exe context (though this is complex and error-prone)
3. Documenting this limitation in the UI where users configure custom commands

The looksLikeWindowsAbsolutePath function on line 58 uses a regex /^[A-Za-z]:[\\/]/ to detect Windows drive letters. This pattern requires exactly one character for the drive letter, but Windows only accepts A-Z or a-z as valid drive letters. While the current regex is correct, consider making it more explicit with a comment or using a more restrictive pattern like /^[A-Za-z]:(?:[\\/]|$)/ to also handle bare drive references like "C:" (though this may not be needed for the current use case).

Also note that the function will return true for UNC paths starting with // (forward slashes), which is technically correct as Windows accepts both forward and backward slashes, but this might be worth documenting.

The matchesShortcut function has complex logic to handle platform differences between macOS and Windows. Specifically, lines 168-172 implement special handling where:

• On non-Mac platforms, if parsed.ctrl is true, it requires event.ctrlKey
• But if parsed.meta is true on non-Mac (line 170), it sets ctrlMatches = true regardless of the actual ctrl key state

This means on Windows, a shortcut defined as "cmd+shift+m" (parsed.meta=true) will match when the user presses Ctrl+Shift+M (because line 162 accepts event.ctrlKey for meta shortcuts on non-Mac). However, line 170-171 then ignores the ctrl key state entirely and always returns true for ctrlMatches.

This could lead to unexpected behavior: if a user has BOTH Ctrl and Meta keys pressed on a non-Mac platform for a "cmd" shortcut, the function would still match. While this may be intentional to handle platform quirks, it should be documented or simplified.

The Windows installer detection logic searches for .exe files containing "setup" or "installer" in lowercase filenames, with a fallback to the first .exe found if no match. This heuristic approach could be fragile if:

1. Tauri changes its naming convention for Windows installers
2. Multiple .exe files are present in the release artifacts with ambiguous names
3. A debug or test .exe is alphabetically first

Consider either:

1. Using a more specific pattern that matches Tauri's naming convention (e.g., checking for the app name in the filename)
2. Having Tauri output a manifest file listing the updater bundle filename
3. Using a glob pattern that's more specific to the actual output (e.g., *_x64-setup.exe or similar)
4. Adding validation that the selected file has an expected size or signature format

For robustness, at minimum add a log message showing which installer was selected.

Reference Windows release assets with stable glob paths

In the release job I checked, Windows artifacts are downloaded from windows-artifacts into release-artifacts, but gh release create only looks under release-artifacts/nsis/*.exe* and release-artifacts/msi/*.msi*; this path assumption is brittle compared with the rest of the workflow (which consumes downloaded artifacts from the root), and when those subfolders are not present the glob is passed as a literal and gh release create fails, blocking publication of the release.

Useful? React with 👍 / 👎.